Could this PR be updated using a rebase instead of a merge. It's hard to tell what changes are unique to this PR.

@langevin-usgs, I'm surprised it is showing up as a merge, I tried rebasing using the following command from a bash console

I must not have pushed correctly. Sorry about this, I'll try again.

A note on replacing the baked-in answers for the 4 SFR smoke tests that were updated with length_conversion and time_conversion to clean-up deprecation warnings: Previously, when using unit_conversion in SFR, it was implied that unit_conversion was the product of a length conversion factor and time conversion factor. This was based on how the input instructions were written. However, after #1154, the following was introduced to the SFR source code, inside the function sfr_check_conversion:

this%unitconv = this%unitconv * this%lengthconv**DONETHIRD

Owing to the fact that lengthconv is raised to the 1/3 power, the results forthcoming from the smoke tests will be different when using time_conversion and length_conversion as opposed to unit_conversion.

@langevin-usgs, it was me that was missing something. The factor 1.486 already reflected the fact that a cube root was applied to 3.28084, kind of embarrassing I didn't pick up on that before. I should've cubed 1.486 when I switched from unit_conversion to length_conversion originally. It after the autotests complete on f96818f, this should be good to go.

@langevin-usgs, I think this one is ready to go. I initially just cubed 1.486 with the thinking that's what was needed to get the autotests to pass, but as you point out, that wasn't necessary. They pass with the true length_conversion value of 3.28084.